%!TEX root = report.tex

\section{Transforming the Model to Code}
\label{sec:transformation}

We used a two-step process for the purpose of transforming the textual model to Java code that can be integrated with the bicycle computer framework, similar to the modelling process:

\begin{enumerate}
\item \textbf{Identifying Requirements:} We identified the required features that the generated cost must have in order to be integrated properly with the framework.
\item \textbf{Implementing the Transformation:} We implemented the transformation using Xtend.
\end{enumerate}

\subsection{Transformation Requirements}
\label{subsec:trans_req}

We identified that the following requirements must be met by our transformation:

\begin{enumerate}
\item \textbf{Robust Integration:} The generated mode functions must be able to integrate with the framework without requiring any modification to the framework each time the transformation is performed.
\item \textbf{Cross-Referencing:} Mode functions may have cross references to other mode functions. These must be accurately preserved in the transformation.
\item \textbf{Error Checking:} The user specified models may have conditions or expressions that generate errors during execution. These must be handled gracefully by the generated code without causing the bicycle computer to crash.
\item \textbf{Overflow Checking:} The bicycle computer has limitations for the amount of data that can be stored. Overflows for variables (such as time and distance) must be handled correctly.
\item \textbf{Display Formatting:} The display strings for modes with different types must be handled correctly. For example, time values have the format `h:mm:ss', and real values have the format `xxx.yy'.
\item \textbf{Computation Order:} The order of mode functions as specified by the user in the model must be preserved as mode functions that appear below might use the value of previously mode functions. Changes in this order might cause the computed value to be incorrect or stale.
\item \textbf{Invisible Modes:} The code for invisible modes must be generated in a manner that they integrate with the existing code for computation but are not shown on the bicycle computer display.
\item \textbf{Preserved Precision:} The precision of calculated values must be preserved. For example, if integers and real values are used together in an expression, they must be handled correctly.
\end{enumerate}

\subsection{Implementing the Transformation}
\label{subsec:impl_trans}

We specified the code generator for our models in Xtend by implementing the \textit{IGenerator} abstract class. The implementation requires that we override the \textit{doGenerate} method, which is passed a handle to the AST for the model as well as file system access to write generated to the file system. We generate two types of files during the transformation:

\begin{enumerate}
\item \textbf{Java Classes:} These classes represent the source code for the mode functions specified in the model. Each Java class generated corresponds to one mode function.
\item \textbf{Modes List:} A text file containing a list of mode identifiers in the order the modes were specified in the model. This file is used to preserve the order of execution of mode functions by the bicycle computer.
\end{enumerate} 

Generating the modes list is relatively straight forward, as we loop through the modes in the AST and output their identifiers to a file.

For the purpose of generating the Java classes, we loop through the modes and called a \textit{compile} method on each mode, passing the root node of the mode as a parameter. The compile method uses Xtend's \textit{rich strings} to specify a template for code generation. For implementing variable parts of code generation, IF-THEN-ELSE constructs are embedded into the code template and custom methods are invoked from within the template if more complex transformations are required. The variable parts of the code include:

\begin{enumerate}
\item \textbf{Mode Type:} The type of the variable which holds the calculated value of the mode function. This depends on the type specified by the user in the model.
\item \textbf{Mode Visibility:} Whether the mode is displayed on the bicycle computer screen or not. This depends on whether they keyword `INVISIBLE' appeared in the model.
\item \textbf{Condition and Expression Evaluation:} The condition and expression specified is different for each mode function.
\item \textbf{Overflow Calculation:} This depends on the type of the mode function. Overflow is calculated differently for time, integer and real values.
\item \textbf{Display String:} This also depends on the type of the mode function. Time, integer and real values are displayed differently on the bicycle computer display.
\end{enumerate} 

A snippet of the code template with the embedded methods and IF-THEN-ELSE constructs is shown in Figure \ref{fig:generator}.

\begin{figure}
	\includegraphics[width=1.0\columnwidth]{imgs/generator.png}
	\caption{Sample Xtend code.}
	\label{fig:generator}
\end{figure} 

\subsection{The Generated Code}
\label{subsec:gen_code}

Once the code generator is specified using Xtend, the Eclipse plugin created by Xtext starts generating code for the model on-the-fly. The textual model is specified in the \textit{src} folder of a Eclipse project, and the generated code is automatically compiled in the \textit{src-gen} folder. If there is any error in the textual model, code generation is stopped until the error is corrected by the user.

A snippet of the generated code is shown in Figure \ref{fig:gen_code}.

\begin{figure}
	\includegraphics[width=1.0\columnwidth]{imgs/gen_code.png}
	\caption{Sample code generated using Xtend.}
	\label{fig:gen_code}
\end{figure} 
